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(57) The present invention relates to a method of 
transfening electronic business cards between a first 
device and a second device, the second device being 
remote from the first device, and both the first and sec- 
ond device being one of a mobile station capable of 
communicating over a mobile communications network 
and of a computer having a connection to the mobile 
communications network. The method comprises re- 
trieving an electronic business card from a business 
card application of the first device, the business card 
application containing a plurality of electronic business 
cards each having a number of data fields. Further the 
business card is transmitted to the second device via 
the mobile communications network; and the received 
business card is stored in a business card application 
of the second device. 
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Description 

[0001] The present invention relates to a method of transferring electronic business cards between a first device and 
a second device. The present invention also concerns a wireless terminal for communicating electronic business cards. 
[0002] At present, communicators are being developed which, in addition to ordinary mobile station functions, also 
have data processing facilities, which enable, e.g., the maintenance of a calendar, and the sending of a fax message 
and electronic mail. The communicators may have or may support several different applications like organiser type 
devices. One type of communicator has been presented in Patent Publication US 5 422 656, comprising a user interface 
having a traditional alpha-numeric keyboard-like keyboard with which it is easier to type, e.g., text messages. In the 
publication in question, the keyboard has been implemented by means of a touch display. However, as traditional 
mobile phones develop, especially as the user interface and displays develop further, also more advanced operations 
will be possible by a traditional mobile phone like device. 

[0003] Publication WO 94/23394 presents an electronic greeting card communication system, comprising an elec- 
tronic mail server for a communicator having different types of greeting cards, which can be browsed and sent to a 
similar communicator, for example, by using radio communication. A drawback of the system is that the greeting cards 
in question can only be sent to a similar communicator. Therefore, the sender should know whether or not the receiver 
has a communicator supporting the greeting card communication system. In addition, for the implementation of the 
system, an off-line electronic mail server, for storing different types of greeting cards, should be separately connected 
to the network for the service in question. Another drawback is that, because the system uses ordinary radio commu- 
nication to transmit greeting cards, the telephone line of the communicator is engaged during transmission. By means 
of the communicator, presented in the publication, graphic images including hand written text can be transmitted. The 
transmission of such an image or a mere hand written message is quite slow due to the large amount of information. 
Publication WO 94/23394 only discusses the sending of Infonnatlon relating to one application or service, i.e. a greeting 
card application. As communicator-like devices have several different applications a problem arises of how to send 
and handle information in relation to different applications. In the WO publication a separate electronic mail server has 
been arranged for the specific greeting card service. However, providing a separate electronic mail server for each 
application of a communicator would lead to a rather complicated and expensive solution. And even then one would 
face the problem of how to handle information relating to different services in the terminal device, e.g. in the commu- 
nicator. 

[0004] Publication WO 95/34998 presents an electronic device that can be remotely programmed by a clerk placing 
a call from a standard telephone on-line to the electronic device. The call is a non-voice communication call and upon 
the electronic device answing the call the electronic device will enter a mode for receipt of programming information. 
The electronic device can be designed to Initiate a retum call for providing inquiry signals to the cell system to verify 
receipt of authorized control signals. The control signals can be sent to the electronic device during the non-voice 
communication call. The control signals are given as DTMF signals using a standard telephone keypad. 
[0005] The present invention concerns a tenninal for a communication network, the terminal capable of supporting 
a plurality of applications and having means of communicating user messages wherein it comprises means for receiving 
user messages having data and a header relating to one of said applications and means for addressing the data to a 
respective application according to said header. Accordingly the terminal may readily have a plurality of different ap- 
plications on such can be arranged into the terminal at a later stage. The later addition of applications can be done by 
direct contact of over the air contact to another device. One user message may contain data relating to one application 
Indicated by the header, or a user message could contain data relating to several application, Indicated by different 
headers, e.g. so that the header indicating a specific application is followed by the data relating to that specific appli- 
cation. 

[0006] User messages contain a limited amount of information and are, therefore, quick to transmit. One type of user 
message is the so called short message. The invention is especially suitable to be implemented by the use of short 
messages. The mobile phone system according to the standard IS-136 uses a so called R data field for the transmission 
of similar short messages. Another type of a user messaging function known in the GSM system according to which 
SMS like messages can be sent as well is USSD (Unstructured Supplementary Service Data, which is more closely 
defined in the GSM specifications, e.g. In the following documents: TS GSM 02.04, TS GSM 02.30, TS GSM 02.90. 
TS GSM 03.38, TS GSM 03.40. A similar messaging fomri called SOC (Service Operator Code) exists in the mobile 
phone system according to the standard IS-136. Communication forms like SMS. R data. USSD and SOC are here 
called user messaging functions and the messages are called user messages despite the fact that such messages 
can as well be sent by an operator and not only by a user. The benefit with this kind of communication is that it does 
not reserve the voice call channel either at all or at least not continuously 

[0007] Similar benefits exists in packet switched communication. A protocol based on PRMA (Packet Reservation 
Multiple Access) for relaying packet switched information is known in mobile communication networi<s. It is also called 
"Packet Radio". The PRMA is a technology for multiplexing packet formatted digital speech or data into a time divided 
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carrier wave. A packet radio service, GSM GPRS (General Packet Radio Service) under development for the GSM 
mobile radio system is used as an example. GPRS is a new GSM service offering packet radio service for GSM sub- 
scribers. GPRS reserves radio resources only when there is something to transmit, allowing the same resources to be 
shared by all mobile stations according to their needs. Accordingly also packet radio transmissions may be used for 

5 transmitting user messages, that reserve the communication channel for only short periods. 

[0008] The intention is that any user messages can be used, but in following mainly short messages will be referred 
to as an example. In addition to being fast to send, the advantages of a short message service can be utilised, such 
as not reserving the voice channel. Application related information can either be pre-stored in a terminal memory 
(permanent memory) or a user may store the application related information in a terminal memory (cache memory) by 

10 contacting a server by means of a terminal. Depending on the application, the user may enter user Input or modify the 
Information In the applications. In another application the information relating to an application may be sent by a service 
provider and the information may be such that it Is not possible for the user to modify it, only to request the service 
provider to modify it. The information readily printed in the application can also be transmitted. An application type 
identifier or header Is preferably added to the transmission, so that a receiving terminal Identifies the short message 

15 as not an ordinary short message, but as a short message containing information relating to and intended for a specific 
application. The identifier can be a code in an address or a control field of the short message, or it can be a code in 
the message part of the short message. Because it has been realised that the short message service, already existing 
in the mobile station system, can be utilised for sending Information on applications, the advantages are, e.g., that 
there is no need to establish an off-line server for sending the application related information, such as, for example, in 

20 the system presented in Publication WO 94/23394. Especially advantageous is that one and the same server, I.e. the 
SMS server (the Short Message Service Centre SM-SC) can be used for sending and forwarding information relating 
to any application, so there Is no need to have separate servers for each application. The SMS server will forward any 
short message and the terminal will address the Information to the correct application according to the header or 
identifier In the message. And since a short message can be sent simultaneously with a circuit-coupled connection, 

25 the sending of the application related information does not engage the terminal's communication line, e.g., in case of 
a simultaneously incoming call. A network like the GSM networi< is maintained by several operators and usually each 
operator has at least one SMS server of their own. In this case naturally any SMS server or several servers may be 
used for the Invention. 

[0009] According to a first aspect of the invention there is provided a method of transferring electronic business cards 
30 between a first device and a second device, the second device being remote from the first device, and both the first 
and second device being one of a mobile station capable of communicating over a mobile communications network 
and of a computer having a connection to the mobile communications network, the method comprising: 

retrieving an electronic business card from a business card application of the first device, said business card 
35 application containing a plurality of electronic business cards each having a number of data fields; 

transmitting said business card to the second device via the mobile communications network; and 
storing the received business card In a business card application of the second device. 

[0010] According to a second aspect of the invention there is provided a terminal having means for wireless com- 
40 municatlon, characterised in that the terminal comprises 

a memory for storing electronic business cards each having a number of data fields. 

means for sending an electronic business card via a mobile communications networic, 



means for receiving an electronic business card via the mobile communications network and for storing a received 
electronic business card in the memory. 

[001 1] The invention will be discussed below in detail by referring to the enclosed drawings and appendices, in which 



45 



50 



55 



Figure 1 
Figure 2 
Figure 3 
Figure 4a 
Figure 4b 
Figure 5 
Figure 6 
Figure 7 



illustrates the flow of a short message from one mobile station to another, 

illustrates connections of a mobile station system to a short message service centre, 

illustrates a user interface of an ordinary mobile phone, 

illustrates segmenting of a message Into frames in transmission, 

illustrates reconstruction of a message in reception, 

illustrates a frame of a short message, 

illustrates one application according to the present invention, 

illustrates another application. 
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Figure 8 illustrates the transmission of the application related information, illustrated in figure 7, from the system's 
viewpoint, 

Figure 9 illustrates the implementation of the terminal according to the present invention. 
Figure 10 illustrates in sequence the function of one application in the tenminal according to the invention, 
5 Figure 11 illustrates in sequence the function of one application in the terminal according to the invention, and 
Appendix 1 illustrates the application related information, illustrated in figure 7. presented in characters. 

[0012] In following the invention will be explained in more detail by using as an example one form of user message 
function, the short message service. For understanding the invention prior art relating to short messages will first be 
10 described by refen-ing to Figures 1-5, and the embodiments of the present invention will be explained by referring to 
Figures 6-11, and to Appendix 1. 

[0013] In digital mobile communications systems, as in the GSM system, it is possible to send so-called short mes- 
sages. In the GSM system, this is known as the SMS (Short Message Service). Thus, in addition to telephone calls 
and data transfer, the GSM system also provides, in the form of a short message service, a paging system-like service. 

15 However, the short message service known from the GSM system is considerably more advanced than an ordinary 
paging system. By means of a mobile station, text messages can be both received from and transmitted to another 
mobile station. One of the advantages of the short message service of the GSM system is also that the short message 
can be sent or received at the same time as an ordinary circuit-coupled communication is open, e.g., during a call. 
Thus, the sending of a short message does not keep the mobile station engaged in case of a possible incoming call. 

20 [0014] The advantage of short messages as compared to telephone calls is that they can be sent to a receiver 
although the receiver cannot be contacted at the time the message is being transmitted. This has been implemented 
by dividing the transmission of the short message, from a first mobile station to a second mobile station, into two parts 
as illustrated in Figure 1 : from a transmitting mobile station MS1 to a SM-SC (Short Message Service Centre), wherein 
the short message is stored and sent further to the actual destination, i.e., to a receiving mobile station MS2, as soon 

25 as contacted. In Figure 2, the connection of the short message service centre SM-SC to a mobile station system has 
been illustrated in more detail. Below, the transmission and flow of short messages between different interfaces, known 
for prior art, will be discussed by referring to Figures 1-5. 

[0015] The structure of a mobile station system and connections for transmitting short messages are illustrated in 
Figure 2. Mobile stations MS are connected to base stations BTS by means of radio communication. The base stations 

30 BTS are further connected, through a so-called Abis interface, to a base station controller BSC, which controls and 
manages several base stations. The entity formed by a number of base stations BTS (typically, by a few dozen base 
stations) and a single base station controller BSC, controlling the base stations, is called a base station system BSS. 
Particularly, the base station controller BSC manages radio communication channels and handovers. On the other 
hand, the base station controller BSC is connected, through a so-called A interface, to a mobile services switching 

35 centre MSC, which co-ordinates the formation of connections both from and to mobile stations. A further connection 
is made, through the mobile service switching centre MSC, to outside the mobile communications network. The afore- 
mentioned short message service centre SM-SC is coupled to the mobile services switching centre MSC. 
[0016] When a user wants to send a short message by means of the mobile station MSI (Figure 1), he/she writes 
a message to be transmitted (using a user interface of the mobile station) and gives the phone number of the mobile 

40 station MS2, i.e.. an identifier of the mobile station MS2, whereto the message is going to be transmitted. In addition, 
the mobile station should have the contact information, i.e., the phone number of the short message service centre 
SM-SC. Normally, this has been stored in the memory of the mobile station, in which case it is not necessary to sep- 
arately input the phone number in connection with the sending of each short message. Thus, when sending a short 
message, the message goes from the mobile station MS to the base station BTS. and from there, through the base 

45 station controller BSC and the mobile services switching centre MSC, further to the short message service centre 
SM-SC. The short message is stored at the short message service centre SM-SC. wherefrom it will be sent further to 
the receiving mobile station MS2, in which case the route of the message is the same as in transmission, but in the 
opposite direction. The short message service centre SM-SC will be informed whether or not the mobile station MS2 
has received the short message. Thus, it can re-send the short message, if the mobile station MS2 has not received 

50 itfor some reason. 

[001 7] Additionally short messages may be sent by a personal computer PC. In this case the mobile services switch- 
ing centre MSC has a connection to a server GTW (Gateway), which has a connection to e.g. Internet. Thus a computer 
PC having a connection to Internet (or directly to the server GTW as shown by the broken line) may fetch a WWW 
(World Wide Web) page from Internet, which physically can be found e.g. from the server GTW. Optionally a service 
55 provider or operator may have a separate server GTW having a connection to the mobile services switching centre 
MSC for sending short messages or other user messages. When using such a WWW page for sending a short message 
the user inputs the connection information (e.g. phone number) of the receiving terminal MS2 and the message to be 
sent, whereby the message is transferred via Intemet and the server GTW to the mobile services switching centre 
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MSG and further to the short message service centre SM-SC from which the message is directed to the receiving 
terminal MS2 via the mobile network. 

[001 8] By means of the short message service SMS of the GSM system, it is possible to send, at a time, a message 
the maximum length of which is 160 characters. The characters are seven-bit ASCII (American National Standard 

5 Code for Information Interchange) characters and, therefore, the maximum length of a message in bits is 1,120 bits, 
i.e.. 140 bytes. Ordinary mobile stations, as the one illustrated in Figure 3. have a small display and an advanced 
keyboard by means of which it is possible to write short messages, i.e.. input different types of alpha-numeric characters. 
The received message is displayed on the display of the mobile station, which enables the display of alpha-numeric 
characters, as illustrated in Figure 3. 

10 [0019] As is well known, transmissions in the GSM system have been divided into frames. When the length of a 
message to be transmitted exceeds the pennissible maximum length of a frame FR, the message M must be segmented 
into parts M1 - M4. and sent in several frames FR1 - FR4, as illustrated In Figure 4a. In reception, the mobile station 
reconstructs the message M. divided into several frames FR1 - FR4. as illustrated in Figure 4b. At a radio interface 
(Figure 2), the maximum length of a frame is nomnally 168 or 184 bits and. therefore, a short message, the maximum 

15 length of which is 1 ,120 bits, must be segmented into several frames. Figure 5 illustrates a frame, a so-called LAPDm 
frame (Link Access Protocol for the Dm channel), to be transmitted at a radio interface, which has normally been divided 
into three fields. The first field is an address field ADD. which contains the address of the destination of the message 
(i.e., a receiving mobile station identifier), given in several bytes. In the GSM system, signalling messages are also 
transmitted within corresponding LAPDm frames. In radio communication, there can simultaneously be two message 

20 flows independent of each other: signalling messages and short messages. These two different flows are separated 
from each other by means of a service access point identifler SAPI to he added to the address field ADD. Its value can 
be 3, indicating signalling, or 0, indicating a short message. The second field is a control field CTRL, which contains 
the sending frame and receiving frame numbers N(S) and N(F). The third field is a data field INFO, containing the 
actual information or data, which contains a maximum of 168 bits of information, i.e., the contents of the actual short 

25 message. 

[0020] In the present invention, using short messages as an example, the transmission of each application related 
information will be identified by means of a specific code, i.e., an identifier, which enables the receiving terminal to 
process the received message directly into an applicafion, as specified, containing the received data. The identifier is 
preferably implemented by using ASCII characters in an information field of the short message transmission frame, i. 

30 e., in a field INFO (figure 5), which contains the actual short message in characters. Alternatively the identifier may be 
in the form of some other character or string code, such as bits, since for sending a short message the data is anyway 
converted into bits. Because the infonmafion relating to the applications is transmitted in a short message, it can also 
be received by means of an ordinary mobile station, which does not support the application service, but is capable of 
transmitting and/or receiving short messages. By placing the application identifier in the field INFO, there is also the 

35 advantage that in an ordinary mobile station, which does not support this type of application service, but is capable of 
transmitting and/or receiving short messages, the application identifier is displayed to a user of the terminal, e.g. a 
communicator and, hence, the user notices not having received an ordinary short message, but the information relating 
to a specific application. In addition, a user of this type of ordinary mobile station can also transmit a message, such 
as mentioned above, by first writing, on the message, the identifier of the application in question in characters, and the 

40 rest of the infomiation correctly divided. The reception of such a transmission by means of a temiinal, according to the 
present invention, will produce a fully received application related informafion record. 

[0021] Alternatively, the application identifier is fonned as a specific bit code in the address or information field of 
the short message (see figure 5). Furthemiore. in this case, an ordinary mobile station can receive the transmitted 
information relating to the specific application, but the user cannot see, in connecfion with the message, that the re- 
45 ceived message is the information for a specific application. In this case, the information for this type of application 
cannot be sent by means of an ordinary mobile stations unless it is modified, so that by entering a specific command, 
it will add the aforementioned bit code because, otherwise, the ordinary mobile station is unable to inform of the ap- 
plication identifier. 

[0022] Figure 6 illustrates an example of an application with an application record pre-stored in a terminal, the user 
50 input information (the application record) on which can be sent to another terminal as a short message. This application 
type is a so-called "Business Card". The application runs business card contents and contains the following information: 
name, position, company, contact information, etc. Each information can be in its own field or the application may only 
have one field, whereinto all the information is fed. Figure 6 also illustrates the transmission of the infomiation on an 
application as a short message. In this case, an identifier of the application type may be, e.g.. 'BC or 'Business Card* 
55 as illustrated in the figure, A terminal, according to the present invention, adds the application identifier (e.g. as letters 
or in other form) to the beginning of the infomiation field of the short message to be transmitted first. The contents of 
the different fields ends automatically in a line feed character. On the basis of this character, a receiving terminal is 
capable of dividing the received information into the con-esponding fields on the application. If this type of message 
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was transmitted as a short message from an ordinary mobile station, a user would write, at the beginning of the mes- 
sage, an application identifier, i.e., in the case of Figure 6. 'Business Card*, after that a line feed character [or], then 
the information on the application in succession or by field (depending on the application specification), i.e., first the 
information in the name field and a line feed character, etc. A received 'Business Card' can be stored in a memory of 
the terminal, where business cards can thus be stored in an electronic form and can be retrieved from the memory 
and looked at by means of the Business Card application. The infonnation in a Business Card application may of course 
vary depending on the device. In some terminals it could mean e.g. only the name and phone number, which can be 
used as a Short Dial application. Accordingly the invention could be used to update contents of a Short Dial application. 
In this way the user could make a backup of the contents of the Short Dial application by sending the contents to a 
service center for storage. If the terminal (e.g. a mobile phone) is later lost/stolen or destroyed in which case the user 
will have to acquire a new terminal, he/she can in addition to activating the terminal, also download (retrieve) all Short 
Dial application contents to the terminal. Of course the same solution can be used for the contents of any application 
in the terminal. Several other applications will be explained here. 

[0023] In the following, as an example, other types of applications will be discussed. These applications can be pre- 
stored in a terminal or arranged into the terminal (by programming) at a later stage. 

[0024] An application "Call Me Back" may contain a person's name, telephone number, address, etc., as well as a 
message that the person should call back. This infonmation can be divided into separate fields or be in the same field, 
as presented above. The aforementioned message to call back may be inseparably linked to the "Call Me Back" ap- 
plication and/or "Call Me Back" (as text) can be written as an identifier, which will also be displayed on the display of 
an ordinary mobile station, in which case, a user of the mobile station in question receiving the message will see that 
it is a request to call back. The transmission of the "Call Me Back" application related information can be connected 
to an outgoing call, so that if the destination terminal does not respond, the transmitting or calling terminal will ask the 
user (the caller) whether a "Call Me Back" notifier should be sent, in which case, if the user's response is positive, it 
will run the application in question on the display with the telephone number of the caller (which it can access, e.g., 
from one's own SIM card, Subscriber Identity Module) ready input on the application data fields. The user may input 
the rest of the information and modify it on the display by the "Call Me Back" application. When application related 
information is sent as a short message, the terminal automatically offers the telephone number of the receiver as the 
destination of the message, which it can pick up from the information of the call left unanswered. 
[0025] An identifier of an application 'Meeting Proposal' can be 'Meeting Proposal*, and the information in the appli- 
cation may contain a convenor's name, time and place of the meeting, as well as its subject. If, in a terminal, there is 
also an electronic calendar application, the transmission of the application related infonnation in question can be con- 
nected to the functioning of the calendar application so that, as a response to the transmission of information related 
to this type of application (Meeting Proposal), a reservation for the meeting at the time in question is made in the 
calendar. The specific application preferably picks up the time of the meeting from the application and enters, in the 
calendar, at the time in question, the rest of the information on the application, such as the place and subject of the 
meeting, as well as the name of the convenor. Correspondingly, when receiving this type of application related infor- 
mation, the terminal automatically searches, in the calendar, for a statement of what may already have been agreed 
upon at the time in question (if entered in the calendar). Thus, the receiver can quickly decide whether to answer 'Yes' 
or 'No' to the meeting proposal. When such an answer is sent, the terminal establishes an application 'Meeting Proposal 
Answer*, whose identifier can be. e.g., 'Meeting Proposal Answer*, and the information in the application may include 
a receiver's name, a time and place of the meeting, subject, answer (Yes/No), and comments. In this case, the calendar 
application in the terminal of the receiver, i.e.. the sender of the meeting proposal, is preferably arranged, so that it 
either confirms or cancels the reservation made in the calendar. 

[0026] Furthermore, as a continuation for the 'Meeting Proposal' application, there may be, in the terminal, an appli- 
cation 'Meeting Confirmation*, whose identifier is, e.g., 'Meeting Confirmation', and the information in the application 
may contain a convenor's name, a time and place of the meeting, and its subject. The tenminal preferably offers to 
send this application related information automatically to all those who answered *Yes' to the meeting proposal. In this 
case, the mobile stations or communicators receiving the information related to this application will confirm the reser- 
vation in question in the calendar. 

[0027] Correspondingly, in the same way as with the 'Meeting Proposal* application, other similar applications can 
be arranged in the terminal, e.g., an application 'Free Time Query', whose identifier can be, e.g., 'Free Time Query', 
and the information in the application may contain a sender's name, a time, a place, and a subject, which a user may 
freely fill in. e.g., tennis, dinner, etc. 

[0028] The terminal preferably functions in this connection in the corresponding way, both in transmission and re- 
ception, as in connection with the meeting proposal applications, i.e., it makes a reservation in the calendar, enables 
the response to a query by means of another application, and. furthemnore, enters in the calendar a possible confir- 
mation or cancellation. 

[0029] By means of an application 'Service DTMF Commands', information can be received, e.g.. from a networt< 
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operator in order to utilise services provided by the operator. An application identifier can be 'Service DTMF Commands', 
and it may have fields for a sender's name, a DTMF command, and an explanation field. The command can be, e.g., 
a password, a user identifier, or something else related to the services provided by the operator. A user may use the 
received command, e.g., a password, when utilising the offered services, in which case, the user does not have to 

5 input the password through the keyboard, because the password can be obtained directly from the application (or the 
information in the application) in question. Other applications to which information may be received from a network 
operator are any applications which require some settings in the terminal before an application can be used. An example 
is an 'Internet Access Point* application which contains information necessary for the terminal to use a WWW browser 
for example. This infonmation may be provider name, phone number, modem Initialisation infomiation, server informa- 

10 tion, IP address (Internet Protocol). Another example of an application that needs some settings is a Fax Box applica- 
tion. A faxbox is a service implemented e.g. in a server, which receives all faxes for a specific user. The user can then 
retrieve the faxes from the faxbox. For retrieving faxes the terminal needs to have the contact information to the server. 
This could be implemented so that when the terminal has received a new fax to the faxbox, the terminal receives a 
notification In a user message of a received fax, but additionally the user message would Include a UID information 

15 (Unique Identifier), I.e. contact information to the faxbox server and other necessary information, such as filename of 
the fax and a password needed. The Fax Box application could function either manually, I.e. by user execution, or 
automatically so that the terminal contacts the faxbox server automatically for retrieving a received fax according to 
the identifier information contained in the notifying user message. The contact can be made as fax call to retrieve the 
fax. Optionally it could be a user message sending the identifier information back to the server and additionally the fax 

20 connection number of the terminal so that the server then can contact the terminal for sending the received fax to it 
via a fax call. 

[0030] Another surrounding for use of the invention is for solutions relating to Intelligent traffic systems, which use 
mobile station like devices as terminals. The terminal according to the invention may thereby have different traffic 
related applications. One example is a 'Position' application with which position requests and responses may be sent/ 

25 received in user messages according to the present invention. Different solutions exist for determining the position. 
The application "Position" may contain position information of a specific address or point of interest as well as the 
description of the corresponding position, a flag describing the reason or mode of transmission, and a reference number 
in case of a response message. After dividing the received information into the corresponding fields, the receiving 
terminal stores the received 'Position' application record in a local memory. The terminal can also send its own position 

30 or a stored position information in a user message to another terminal or to a server. This can also be done automatically, 
e.g. in case of emergency situations. For emergency situations the terminal may have separate "Emergency Indication" 
or "Panic Indication" applications which automatically include information about the sender, which the sender may 
modify in the application, about his vehicle and his position and other relevant information needed for emergency 
situations. 

35 [0031] Additional applications for traffic purpose is for example "Trip Request" and "Trip Response" applications (or 
generally "Travel" application), which is a travel assistance application. In this application the terminal can send out a 
Trip Request, preferably containing the actual position of the terminal as a starting point and a selected position out 
of the stored position application records for the destination of the trip. As a response to a Trip Request the terminal 
may receive 'Trip Response' messages, which may contain instructions for the trip, such as turn instructions or public 

40 transport connections. 

[0032] Also the terminal may have a Service application with infonmation that can be important for service purpose 
such as the original serial number of the terminal, manufacturing month, repair month and month when modifications 
have been done (e.g. modifications to software). The information in the Service application can be sent in a user 
message from the terminal to for example the operator or a service station. 
45 [0033] Another possible application is a Phone Book application for sending phone number queries to a service 
provider keeping a Phone Book service. The query may include information like name, city of residence, landline/mobile 
number etc. As a response the service provider sends a user message which has the phone number or numbers and 
for example the information that the user sent originally. 

[0034] Another type of application which will provide the terminal with many possibilities for having additional services 
50 and applications is a "Menu" application, in which the terminal includes an application which is capable of creating 
menus in the terminal according to a received user message. The menus are preferably stored in a permanent memory, 
such as memory 14 in Figure 9 in order to create menus, which can be used permanently in the terminal. The user 
message contains infomiation according to which the "Menu" application creates or updates menus in the tenminal. 
This allows access to a big variety of services, which the operator can update in the user's terminal over the air, i.e. 
55 without the need for the user to take the terminal to a service place. Operators are provided with a very powerful tool 
to personalize the handsets their subscribers use. This tool is operator specific menu structure in the handset which 
can be different from subscriber to subscriber, if needed to. The menu structure can be dynamically updated over the 
air without any user assistance. In following is an example of menus that can be created and updated and which thereby 
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can provide the user with additional services accessible by activating the command in a menu. Originally the terminal 
may include some basic menus or no menus at all. All the menus and sub-menus shown in the following example can 
be crated by sending a user message relating to the Menu application. 

MENU: 

[0035] 

Phone Settings 
Operator Sen/ices 

Call Customer Service 
Download Ringing Tones 

Rock around the clock 
Those were the days 
Smoke on the water 

Download SIM Software 
New Offerings 

<any operator specific supplemental service> 

Local Services 

Join Wal Mart direct-ad 
Traffic at Dallas 1-75 
Thunderstorm Warning! 

Personal Services 

BigBook 
Yellow Pages 
Stock NOKA 
US Weather 
Send eMail 
Find Restaurant 
Holiday Travel Inc. 

Memory Settings 

[0036] Accordingly the menu or menus can include main-menus and sub-menus as shown above, where the main 
menus Operator Services, Local Services and Personal Services include sub-menus. These sub-menus may further 
be divided into sub-menus, e.g. sub-menu Download Ringing Tones can be divided into sub-menus according to ring 
tone melodies (Rock around the clock, Those were the days, Smoke on the water) which can then be chosen as ring 
tones by selecting the specific sub-menu and activating it as a command. The command is sent to the service provider 
as a user message according to the invention and as a response to the user message the operator may send the ring 
tone coded into a user message which can then be stored into a ring tone memory of the terminal. 
[0037] Selections made in sub-menus cause wide variety of actions. Entries in the sub-menus can be associated 
with URL (Uniform Resource Locater) infomiation, which can be used to fetch information from Internet, send email 
to Internet recipients, etc. In addition, supplementary services can be initiated directly from these entries; a special 
form of URL can be used to convey supplementary service related information or a call or user message. Actions may 
cause information to be sent to the terminal by a network entity, e.g. enables selection and then downloading of ringing 
tones as explained above. Thereby the Operator Services menu can cause information to be fetched from Intemet 
based on URL information, it can cause email message to be sent to a recipient, it can cause operator specific sup- 
plementary service strings to be sent to the network, or it can cause call initiation. The Local Services menu support 
services that are targeted to a specific geographical area. A menu is generated from Volatile' services that are available 
in a certain area, at a certain time. The users can browse through these services, and pick those that interest them. 
This facility provides an easy way to direct infomnation (or advertisements of services) to phone users traveling through 
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or in a geographical area. For example, one of the services, "Traffic at Dallas 1-75" could become available as the 
phone user approaches the Interstate highway 75 in Dallas area. Instant traffic information can be achieved by selecting 
the service from the menu. The Personal Services menu can be compared to the bookmark list in a normal WWW 
browser (World Wide Web). The phone users have the ability to add items to the list, to edit them, and to remove them. 
The Personal Services menu enables users to easily initiate wide variety of services. Service information can be moved 
from the list of operator specific or local services to the personal service list. Again, Personal Services menu can cause 
information to be fetched from the Internet based on URL information, it can cause email message to be sent to a 
recipient, or it can cause operator specific supplementary service strings to be sent to the network or it can execute a 
call or cause a user message to be sent. For example the sub-menu command US Weather will result in the terminal 
receiving information on the weather in the United States. 

[0038] Menu creation wilt be explained in more detailed in following. Menu creation is controlled and implemented 
by a processor and the Menu application which is stored in a memory and run by the processor. In following a protocol 
is explained according to which the Menu application may be implemented as software run by a processor. The terminal 
will be described in more detail later in relation to Figure 9. 

[0039] The protocol defines predetermined commands according to which creation and change of menus and menu 
structures are controlled. There are four Item primitives in the protocol which are add, remove, list, and item capability. 
These item primitives will be accompanied by other menu-item definitions as will be explained. 
[0040] The first primitive item is item-add, which adds a menu or suthmenu. The command sequence may include 
following definitions, which can be sent to the terminal in a user message: 

<item-add> menu-item-token 

menu-group-name 

menu-item-name 

menu-item-type 

menu-item-help 

menu-action-list 

[0041] The definition menu-item-token can be an optional command to be used by the server for authorization pur- 
poses if security is needed, if not then it can be omitted. Once a menu item has been sent to a terminal with a menu- 
item-token set, no command can be given to change or remove the existing menu-item without the same menu-item- 
token. This kind of authorization feature can be used in connection to other applications described here as well, not 
just in relation to the Menu application. For example a ring tone would be updated only if it is accompanied by the 
connect authorization word or code, like the menu-item-token. The definition menu-group-name specifies the menu 
group into which the menu item with name menu-item-name is put. If a menu item with the same name in the same 
group already exists (and the server is authorized to update the menu item by the correct menu-item-token), then the 
existing menu-item is replaced with the new one. The name of the menu group is placed in apostrophes in context with 
the definition. 

The definition menu-item-name defines sub-menu names or commands under the menu group (or main menu). Like- 
wise the name of the sub-menu is placed in apostrophes in context with the definition. 

Both menu-group-name and menu-item-name have a reserved character of *:* which has a special meaning of line- 
feed inside the menu group name, i.e., the name "phonersettings" menu item name will show on a terminal as 'phone* 
on the first line, and 'settings' on the second line. Additionally menu-group-name has a reserved character of which 
has a special meaning of indicating change of hierarchy level in multiple hierarchy menus. 

[0042] Menu-item-type indicates what is the type of the menu item. The menu item can have the following types the 
explanation of which is below: normal, volatile, selected (volatile), and link 

Nonnal menu items are stored in the handset normally. 

Volatile menu items are one-of-menu selection items for multiple choice menu items. 
Selected (volatile) menu item indicated the currently active volatile menu item. 

Link menu items indicate to the terminal that it must request the volatile selection items from the server. 

[0043] The definition menu-item-help is a text string which is shown when the user of the handset needs help re- 
garding the current menu item. It is handset specific does the handset automatically show the help text when for 
example an idle timer expires. Similar additional definitions may be tied with menu-item-help as was described above 
for menu-group-name and menu-item-name. 
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The definition menu-action-list is a list of actions which can be activated from the menu. The actions can be for example 
of the type action-send-message or action-call-control Action-send-message causes a user message to be sent in one 
of many methods. The method is dependent on message type, which can be any user message as has been specified 
earlier (SMS, USSD, R data, SOC. Packet Radio). Action-call-control causes a call to be made in one of many methods. 
5 The method is dependent on call-control-type, which can be voice call, data call, fax call, or ss ( a supplementary 
service string is sent to the network). 

[0044] The second primitive item command, item-remove, causes a menu item identified by menu-group-name and 
menu-item-name) to be removed from the terminal provided that authorization (based on menu-item-token or on an 
authorization list) does not fail. The command sequence can be following: 

10 

<item-remove> menu-item-token 

menu-group-name 

menu-item-name 

15 [0045] The third primitive item command. Item-list, causes the terminal to send a list of menu-item-names to the 
server from which this command was originally sent. The server can specify the menu for which the list of items is 
requested. When menu-item-token is given, only those items with matching token will be retumed. The command 
sequence can be following: 

20 <item-list> menu-item-token 

menu-group-name 

[0046] The fourth primitive item command, item-capability, can be used to add or to remove extra capabilities from 
25 a menu item. This command can be used e.g. to add an icon to a menu item according to the specified capability. The 
command sequence can be following: 

<item-capability> menu-item-token 
menu-group-name 
30 menu-item-name 

menu-item-capability 

[0047] Authorisation to change menus may defined more closely by authorisation primitives. There are three author- 
ization primitives which are add. remove, and list. Authorization lists may especially be used for operator and manu- 
35 facturer menus. It is implementation specific how many entries the temiinal is capable of storing in the authorization 
list of each menu. The authorization primitives and commands for entering them into the terminal can be implemented 
in a similar manner as was described above for menu-item primitives. The authorization commands are privileged in 
such sense that they will be accepted only for a menu with authorization list active, and when sent from an already 
authorized server. 

40 [0048] The first primitive authorization command, authorization-add, can be used to add one or more new authorized 
servers to the list of authorized servers for the given menu (menu-group-name). The menu-authorization-server-list 
comprises one or more lines of information, each defining one authorized server. For GSM/SMS, an authorized server 
is defined by a pair defining identity of the short message service centre and of the server, e.g. (MS-ISDN of a SMSC 
which is the mobile subscriber international ISDN number for the SM-SC; MS-ISDN of the server, which is the mobile 

45 subscriber intemational ISDN number for the authorized server). The command sequence can be following: 

<authorization-add> menu-group-name 
menu-authorization-sen/er-list 

50 [0049] The second primitive authorization command, authorization-remove, can be used to remove one or more 
authorized servers from the list of authorized servers for the given menu (menu-group-name). The command sequence 
can be following: 

<authorization-remove> menu-group-name 
55 menu-authorization-server-list 

[0050] The third primitive authorization command, authorization-list, can be used to request the handset to send the 
list of privileged servers for a requested menu (menu-group-name). The availability of this command depends on the 
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handset implementation. The command sequence can be following: 
<authorization-list> menu-group-name 

5 [0051] The Menu application has stored the meanings of different commands. This may be done for example in the 
form of a script interpreter as software in the terminal. An example of script interpreters is an interpreter understanding 
a specific programming language. Accordingly, when a specific command or sequence of commands is received in a 
user message according to the invention, the Menu application implements operations accordingly, such as adding or 
removing menus and/or sub-menus. The above are to be treated as examples. Naturally different commands may be 

10 used than the above, and they may be shorter in order to fit more commands into one user message (e.g. into a short 
message). 

[0052] When using the Menu application with short messages the number of one or several short message service 
centres (SM-SC) can be related to a menu so that when activating a user message by a menu item the message would 
be sent via a specific short message service centre or to any SM-SC of a specific list. The numbers of a specific or 
15 different SM-SCs can be sent from the network to the terminal in a user message, e.g. when a menu is created or 
updated. This would allow more possibilities for services and quicker and more reliable transmission of user messages, 
when a special service (or the server providing that service) accessible via a specific menu command is connected to 
a specific service centre. 

[0053] An example of creating a menu for ringing tones is disclosed in Figure 1 0 as a sequence of displays to illustrate 
20 what the user sees on the display. The command "NEW RINGING TONES" is sent in a user message to a server of 
a ringing tone service provider in order to request for latest ringing tones. As a response the server sends a user 
message containing information relating to the Menu applications for creating a menu, from which the user can select 
a new ringing tone. The user selects the desirable ringing tone from the menu (selects ring tone 'Popcom'). The selection 
activates a user message to be sent to the sen/er indicating the desired ring tone. After a while the terminal receives 
25 the ring tone from the server. A received ringing tone is indicated to the user using the "RINGING TONE RECEIVED" 
notification. The user can accept or reject the ring tone. Once the user has given acceptance, the selection menu with 
the options "Save" and "Playback" displays. If the user selects the Save -option the received ringing tone is saved to 
the phone and it appears to a ringing tone options menu. The saving is indicated to the user by displaying a "SAVED" 
confimriation note after which the phone goes to the idle state. If the user selects the Playback - option the received 
30 ringing tone is played to the user and after that the original selection list displays again. If the user gives a rejection of 
the new ring tone, the received ringing tone is discarded, the selection list is removed from the screen, and the phone 
goes to the idle state. 

[0054] Another example of application of commands producing functions in a terminal will be described in following 
with reference to Figure 1 1 . The example relates to querying the timetable of certain flights. First it is assumed that the 

35 user already has a created menu command for this purpose in the terminal, which command the terminal may have 
received according to the invention. The menu item FINNAIR FLIGHTS TIME-TABLE includes readily the contact 
information of the server to which the request is to be sent or if the terminal has a specific contact, then the request 
will be forwarded from that contact to the server with the service to be requested, i.e. the flight schedules. By activating 
the menu item FINNAIR FLIGHTS TIME-TABLE a first user message includes a code or signs which indicate sending 

^0 a request, e.g. 

1 ) The first sent user message is following: 
??? FLIGHTS 

where "??? FLIGHTS" is a command indicating to the receiving server that it is a request for Finnair flight time- 
rs tables. The user does not see the contents of the message but rather sees notes on the displays indicating that 
the request is being sent, that it has been sent and that the user shall wait for a while until a reply comes. These 
notes are shown after step 1 ) in Figure 1 1 . After this the terminal receives a user message from the service provider, 

e.g. 

2) The flrst received user message is following: 
50 ++Finnair flight queryCR 

<From:CR 
<To:CR 
<+Date: CR 

where ++ indicates to the terminal to wait for a reply and the text after that is displayed on the terminal screen for 
55 a while and CR (Carriage Return) ends the command row. The sign indicates a letter entry mode so the text 

after the '<' sign is displayed on the terminal screen as seen in Figure 11 and it allows the user to enter letters. In 
this example OUL is entered indicating that the request concerns a flight from the city of Oulu. The user ends the 
entering by a predetermined command (e.g. pressing of a specific key). Similariy a next entry mode indicating 
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destination is showed on the display, whereby the user enters HEL entered Indicating that the request concerns 
a flight to the city of Helsinki, The sign '<+' indicates a number entry mode so the text after the sign is displayed 
on the tenninat screen as seen in Figure 11 and it allows the user to enter numbers, which in this case is the date 
of the requested flight. When the last command is reached the terminal asks if the fonm is finalised and if the 
request can be sent, and if so the terminal creates and sends a second user message containing the entered 
information, e.g. 

3) The second sent user message is following: 
++Finnair flight queryCR 

<From:OULCR 
<To:HELCR 
<+Date: 041296CR 

which the service provider (server) is able to interpret according to the predetermined commands. Again the user 
does not see the contents of the user message, but is displayed predetemiined notes on the temninai screen. As 
a response to this request the terminal receives a second received user message from the service provider, e.g. 

4) The second received user message is following: 

Finnair flights from OUL to HEL 04/12/96:CRAY3434, 06:05 AY3436. 07:00 
AY3438, 07:30 AY3440. 10:15 

whereby the terminal displays the relevant information (not the application specific codes) to the user as shown 
in Figure 11 allowing the user to scroll through the information (e.g. with arrow keys or other scrolling means) and 
as a response to a quit command from the user interface, retums to showing the original menu command. 

[0055] The example described above and shown in Figure 11 illustrates how user messages according to the inven- 
tion can be used for providing new services to a tenninal, like a mobile phone, by having predetermined signs corre- 
sponding to predetermined commands. These signs and commands can be stored in a memory In the temriinal device 
of a user (e.g. a mobile phone) or of a service provider (e.g. a computer) and can be implemented by software run by 
a processor for performing the predetermined commands. Also in this way the terminal can be programmed to function 
in a specific manner. The Menu application allows to introduce new applications into the tenninal. For example the 
previously mentioned Phone Book application could be introduced to the temiinal by a first user message from the 
service provider creating a first menu (e.g. menu 'Phone Book') after which when sending a request to the service 
provider the tenninal would first receive a menu structure for sending the information needed to get the relevant phone 
number as was described earlier and after sending the relevant information the terminal would receive a response 
including the phone number. This procedure could be similar to what was described above in connection to Figure 10 
for querying the timetable for a flight. 

[0056] In the following, another application, which has not been pre-stored in a terminal, will be discussed by referring 
to Figures 7 - 9, and to Appendix 1 . By means of the terminal, electronic mail can be sent through a mobile communi- 
cations network. Correspondingly, by means of the terminal, a communications link can be established to the Internet 
through a mobile communications network. This communications link can be established by connecting a computer to 
a mobile station, by means of a data card, in which case a user interface of the computer can be utilised for reading 
pages and services on the Intemet. Alternatively, a communications link to the Internet can be established by means 
of a communicator, which comprises in itself a user interface for reading pages and services on the Intemet. A com- 
municator of this type has been presented in Finnish patent application titled 960894 filed on 26.2.1996 with con-e- 
sponding patent applications claiming priority from the above and filed at the EPO on 27.1 . 1 997 with application number 
97101184.6 and in the United States on 23.1 .1997, the description of which is incorporated herein by reference thereto. 
Computer programs by means of which a communications link to different pages on the Intemet can be established, 
and which enable the so-called surfing on the Intemet, are called WWW (World Wide Web) browsers. Currently, a 
number of different companies have their own service pages on the Intemet, through which a user may order information 
on a service or make orders and reservations. This is accomplished by establishing communication to such a service 
page and by inputting information on what is required from the provider of services. This information can be either text 
or selection boxes/keys, by means of which selections are made according to the 'tick the appropriate box' principle. 
An example of such a service page has been given in Figure 7, which illustrates a query page for bus schedules, which 
a user can download onto the display, e.g., through a telecommunications network, such as the Intemet. In this case, 
the page will be stored in the communicator's memory (e.g., hidden memory) for the duration of the use of the page, 
and it can be stored in the permanent memory by means of an off-line command. On the page, selections can be made 
in boxes and additional requests and, for example, contact information for feedback, can be written in the space that 
may be available on the page. Alternatively, the communicator may automatically offer its own telephone number as 
the address for the feedback, as presented above in connection with the "Call Me Back" application. As is known, a 
page on the Intemet can be presented in the HTML language (Hyper Text Mari<up Language. Transfonning and pre- 
senting a service page from the Intemet in the HTML language is known from WWW browsers. 
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[0057] Appendix 1 illustrates the Internet page in Figure 7 transformed into the HTML language in order to present 
the page in characters. The characters can be sent in a short message. In the GSM system, a message, whose max- 
imum length is 160 characters, can be sent in a short message. Therefore, in the present invention, a whole page is 
not preferably transmitted, but only certain information of it. In the HTML code on this service page, both the infonnation 
to be displayed on the display and the hidden information have been specified. Different types of data have pre-set 
codes. To send the page according to the present invention, Information necessary for the sending of an application 
related information is added to the HTML code of the page, and this information is hidden from a user. I.e., it will not 
be included in the graphic presentation of the page. The information has preferably been an-anged on the page by the 
provider of services. Thus, in order to be able to send such a service page as a short message, the provider of services 
should support the opportunity in question by including in the page in question specific information, at least the tele- 
phone number to which a message should be sent. At arrows A- J, illustrated in Appendix 1, there has been given 
infonnation, which is added to the HTML code in order to send the information on the page in a short message according 
to the present invention. For example, at the arrow A, a coding method can be indicated by means of a presented 
specification. The arrow B indicates that the type of the form is a query; the arrow C gives the name or abbreviation 
of the provider of services; the arrow D indicates the type of service in question; the arrow E gives the name of the 
service page; the an-ow F indicates which form the terminal should use to display the answer; the arrow G gives the 
telephone number of the receiver, i.e., the provider of services; the an-ow H gives the telephone number of a short 
message service centre through which the message is transmitted. The information indicated by the arrows G and H 
is essential, at the least. The arrows I and J indicate other specifications, which can be added on the HTML page as 
necessary. After the arrow J comes the actual HTML code that forms the WWW page in question. 
[0058] Con-espondingly. a temninal can be pre-set to find specific identifiers in the HTML code, which it picks up from 
the HTML code and attaches as characters to the data field INFO of the message to be sent (see figure 5). For example, 
a selected time is found on a line indicated by an arrow K as a variable do, after which the selected time is presented, 
which will be obtained as a response to a press of the SEND button. As illustrated in Figure 7, an uppemiost selection 
box has been mariced, which is shown in the HTML code in Appendix 1 as "IBI" on a line indicated by an an-ow L as 
a code checked. When a user presses the SEND button, a variable opti will get the value of the selection box, which 
has been selected when pressing the icon, i.e., the value "181", assuming that the uppermost selection box has been 
selected. 

[0059] In the example, illustrated in Figure 7 and Appendix 1 , a temiinal such as a communicator may, in this way, 
pick up information from the HTML code on lines indicated by the arrows C, D, G, H, K, and L. The tenninal will place, 
at the beginning, an identifier indicating the application type, here as an identifier "WWWSMS". In addition, from the 
point indicated by the arrow C, a service provider identifier, on the basis of which the receiver will recognise the infor- 
mation in question, e.g., here a character C, can be placed in front. Furthemore, the service name can be placed 
con-espondingly from the point of the an-ow D, the telephone number of the sender from the point of the arrow G, the 
telephone number of the receiver from the point of the arrow D, and the selections made by the user from the points 
of the anrows K and L, which functions, so that the values of all the variables (here variables do and opt1} on the page 
are placed in the message. The values of the variables are preferably obtained as a response to a send command, i. 
e.. to a press of the SEND icon. In this case, the data sent in the short message are, e.g., as follows: 

WWWSMS[cr] 

CErSa(f] 

DTreBus[fl 

G+358505337397[f] 

H+358508771010[f] 

08:00 161 

.in which the [cr] character indicates a line feed and the [f] character is a field separator, which indicates the ending of 
the field and. on the last line, all the selections made by the user are shown, i.e.. that the user requests information on 
the timetable of the buses of the line 1 B1 (Holvasti-Keskustori) departing after 08:00 o'clock. On the basis of this, the 
provider of services is able to send to the user information on the timetable of the bus line in question. 
[0060] When this type of service page has been downloaded from the Internet, it can then be stored in the memory 
of the terminal, and later re-used without establishing a communications link to the internet. Correspondingly, as to 
application related information pre-stored in the terminal, a specific identifier can be attached to the message, in con- 
nection with the sending of the infonnation on the application illustrated in Figure 7 and Appendix 1, which indicates 
that the application is a service page downloaded from the Internet, e.g., the identifier "WWWSMS' as in the example 
discussed above or •WWWSMS45*. in which the beginning indicates that it is a service page and the last two characters 
may indicate, e.g., the provider of services. 

[0061] Sending infonnation of a service page in a short message according to the present invention saves consid- 
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erably the power consumption of the temiinal and, thus, prolongs its useful life, which is an important objective In 
battery-operated devices. In addition, savings are made in phone call expenses, when query information can be sent 
together with the short message. The whole system has been illustrated In more detail in Figure 6. A terminal according 
to the present invention has been presented with reference numeral 1 , by means of which a communications link 

5 (reference 1 01 ) to the Internet INT can be established. The invention could also be implemented by means of a device 
having means, according to the present invention, for processing information on an application into a short message, 
which is sent through an ordinary mobile station by coupling the device to the mobile station. Such a device could be, 
e.g., a computer. To simplify matters, only a communicator will be discussed here as an example of a temiinal according 
to the invention. When the communications link Is established to the Internet by means of a communicator 1 , a service 

10 page of a provider of services can be downloaded (reference 1 02) from the Internet into its memory and user Interface. 
By means of solutions known for prior art, the user, after having filled In the page, has sent the service page by means 
of the communicator 1 to a server SERV of the provider of services, I.e., along route 101-101'. This means that the 
communications link to the Intemet should be open for transmission. In a system according to the present Invention, 
the information on the service page is sent (reference 103) in a short message to a short message service centre 

15 SM-SC, which sends it further (reference 104) to the server SERV of the provider of services. The transmission of the 
service page through the Intemet. according to prior art, lasts considerably longer than the transmission of a short 
message and, thus, due to the present Invention, a shorter transmission time Is achieved, thereby, efTecting a saving 
in power, since, in the communicator, transmission and reception. In particular, consume a lot of power compared to 
other functions. In addition, in the solution according to prior art. a circuit-coupled connection is in use in transmission. 

20 in which case the communicator is engaged during transmission. On the other hand, the sending of a short message 
does not engage the circuit-coupled connection, and an additional advantage is that the short message service centre 
SM-SC will send the message to a receiver later, if the telephone number of the provider of services happens to be 
unreachable during the transmission of the message. 

[0062] When the user has in this way sent the provider of services a query, the provider of services will interpret it 
25 and respond to it. The provider of services may also send the response (reference 1 05 - 1 06) as a short message, and 
it can, in the same way as in the transmission of the service page, contain HTML codes, which the communicator will 
interpret and transform Into a form legible to the user. Thus, the sending of a response has the same advantages as 
the sending of an query. For the response, the original service page downloaded from the Internet, can be arranged 
on the display by the application running HTML code pages, so that it has space (fields) ready for the response. When 
30 the user sends the query to the provider of services, he/she stores the page in the communicator. The response will 
have, in the same way as in transmission, specific identifiers, in which case, as the response amves. the communicator 
will run the specific application and open, on the display, the page in question and place the response in the area 
provided for it. whereupon the situation from the user's viewpoint looks as If he/she has received a WWW page con- 
taining the response. The response from the provider of services can also be. e.g., in a fonn of an application 'DTMF 
35 Service Commands' or In a corresponding form. 

[0063] Instead of an application identifier being indicated as a code In a short message (in data field INFO), it can 
be indicated in an address field ADD of the short message, in which case it is given In bits. A certain byte in the address 
field of the transmission frame of the short message is a so-called TP-Data-Coding-Scheme, which has been specified 
in the GSM specification as GSM 03.40 and 03.38. The four less significant bits of the byte can be freely used, where- 
to upon they can be used to indicate the type of the application to be sent according to the present invention. Different 
types of applications can be indicated by means of these four bits according to the example given in the following table, 
wherein bits are marked with references b3 - bO, in which bO is the least significant bit (LSB) of the aforementioned byte: 



45 



55 



b3 


b2 


bi 


bo 


type 


0 


0 


0 


0 


Business Card 


0 


0 


0 


1 


Call Me Back 


0 


0 


1 


0 


Meeting Proposal 


0 


0 


1 


1 


Meeting Proposal Answer 


0 


1 


0 


0 


Meeting Confirmation 


0 


1 


0 


1 


Free-TimeQuery 


0 


1 


1 


0 


Position 


0 


1 


1 


1 


Trip request 


1 


0 


0 


0 


DTMF ServiceCommands 


1 


0 


0 


1 


Menu 


1 


0 


1 


0 


WWWSMS01 


1 


0 


1 


1 


WWWSMS02 
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(continued) 



5 



b3 


b2 


bi 


bo 


type 


1 


1 


0 


0 


WWWSMS03 


1 


1 


0 


1 


WWWSMS04 


1 


1 


1 


0 


Phone Book 


1 


1 


1 


1 


Short Dial 



io [0064] Identifying the application in this way does not take the space reserved for the character length (max. 160 
characters) of the message. When this type of identification is used, it Is also possible to receive the information on 
the application sent by means of an ordinary mobile station, but in this case, the user is unable to see, in connection 
with the message, that it is the Infomiation from a specific application, unless this information is programmed in the 
mobile station. Neither can the information on this type of application be sent by means of an ordinary mobile station, 

15 because the user is unable to add this type of identifier to the message. Naturally an ordinary mobile phone does not 
support the different applications. 

[0065] In the following, the implementation of a terminal, in this case a wireless temitnal according to the present 
invention, and its operation In transmitting and receiving an application related information will be discussed in more 
detail by referring to Figure 9. 

20 [0066] In Figure 9, there is a block diagram of the implementation of a terminal according to the present invention, 
which in the figure is shown as a device also having means for transmission over the air such as a mobile phone. 
However a similar implementation can be used for a terminal device of a service provider which usually does not have 
means for direct radio frequency transmission but is connected to such means (e.g. a base station) over the network 
as is shown in Figure 2 (e.g. the personal computer PC or server GTW). The terminal is preferably a mobile phone or 

25 communicator, which has circuits and a user interface that enable the processing of different applications. The terminal 
1 in Figure 9 comprises, for communication using radio communication, a radio unit RU (the reference has not been 
marked in the figure), which comprises a transmitter branch 2, known from an ordinary mobile station, (comprising 
blocks implementing coding, interieaving. ciphering, modulating, and transmitting), a receiving branch 3 (comprising 
receiving, de-modulating, de-ciphering, de-interieaving, and implementing blocks) and, for transmission using radio 

30 communication, a duplex filter 4 that distinguishes between a received and transmitted message, as well as an antenna 
5. The terminal has a main control circuit 6 that controls its operation. Furthermore, the main control circuit 6 comprises 
still a RU controller 7 that carries out control functions of an ordinary mobile station. In addition, the terminal main 
control circuit 6 comprises blocks 8 - 12 for carrying out the functions of a data processing unit of the terminal and for 
sending application related information as a short message according to the present invention. Thus, the blocks 8-12 

35 can be said to fomn a data processing unit DU of the terminal. The controls of the radio unit RU and the terminal's data 
processing unit DU do not have to be integrated into the main control circuit but, instead, they could also be implemented 
apart from each other, so that the RU control circuit 7 is on the radio unit's side, and on the data processing unit's side, 
there is the DU processor 8, which is in connection with the RU control circuit 7 for establishing communication between 
the radio unit and the data processing unit. 

40 [0067] In the implementation illustrated in Figure 8, a first memory 13 is coupled to the main control circuit 6. The 
first memory can be a volatile memory, e.g.. RAM, where the main control circuit stores in-use data. In addition, the 
temriinal has a second memory 14, which is preferably a pemrianent memory 14. wherein the terminal's application 
programs performing different kinds of services and running the different types of applications, other data essential for 
the functioning of the terminal, and any other data which a user wants to store permanently, are stored. Alternatively, 

45 the application related information can be stored off-line in a memory of an extemal smart card, coupled to the terminal, 
wherefrom there is a connection to the main control circuit 6. This type of smart card is known, e.g., from the GSM 
mobile communications system, as a SIM card (Subscriber Identity Module), which usually has storage, e.g., for storing 
telephone numbers. In this case, new applications can be updated in the terminal by simply updating the memory of 
the smart card. 

50 [0068] For viewing applications, the terminal has a display 1 5, and for inputting data, a keyboard or other input device 
16, such as a touch display 

[0069] In the case where the data processing unit DU and the radio unit RU are implemented as functionally inde- 
pendent units, both of them should, however, have either common or separate memories 13, 14, and a user interface 
Ul. Communication between the units would be established by means of a connection between the DU processor 8 
55 and the RU control circuit 7 which, in this connection, is referred to as an external control Interface ECl. 

[0070] In the following, we will discuss the implementation and operation of the tenninal, when transmitting application 
related information. By means of the user interface Ul, the required application is brought onto the terminal's display, 
in which case, on the basis of 16 commands from input devices, the control circuit 7 retrieves from the memory 14, 
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wherein applications 17, 18 programmably handling the application related information have been stored, the selected 
application stored therein onto the display 1 5 or retrieves a service from the telecommunications network as presented 
above. The application relating to a service is processed in the DU processor 8, which also controls the transmission 
of application related information by maintaining contact with the RU control circuit 7, which controls the operation of 

5 the radio unit RU. An application contains information, as illustrated in Figure 6. The information can be in one or more 
fields, which have either been ready filled in (if a record of an application already containing infonnation was retrieved 
from the memory) or its data fields are empty, in which case a user may input information In the fields by means of the 
input devices 16 or modify the infonnation in the fields. When the application contains the required Infomiation and the 
user enters, by means of the Input devices, a command to send the application related information, the DU processor 

10 8 forms, from the information on the application, a line of characters, so that it places at the beginning of the line the 
application identifier (unless the identifier is given in the address field), and after that, e.g., the information contained 
in the different fields, separated by line feed characters, in alpha-numeric characters including the possible space 
between the characters. Hence, the DU processor 8 comprises, for the processing of the characters, word processing 
program-like functions, which have been implemented by programming and stored in the memory 14, wherefrom the 

15 DU processor 8 retrieves the program and performs the functions according to the program. The DU processor 8 
transfers the line of characters formed to a SMS transmission controller 10, which adds to the message address infor- 
mation, i.e., the information on the destination either on the basis of the user input information or by retrieving it from 
another application, e.g., from the calendar application as presented above. Thus, this type of SMS transmission con- 
troller is a kind of bit and/or character generator. The calendar is preferably implemented as an application program, 

20 stored in the memory 14, which is used by means of the DU processor 8, Thus, communication between two different 
applications 1 7 and 1 8 is established by means of the DU processor, which thereby, e.g., on the basis of time information 
retrieved from one application, opens up or enters information in the other application (e.g. in the calendar at the time 
in question). 

[0071] When address information has been added at a SMS transmission controller 10, the message is transferred 

25 into an outbox 1 1 , which tries to send the message, and which has a buffer wherein the message is stored in case the 
transmission fails. If the transmission fails, the outbox 11 re-tries to send the message. When the DU controller 8 
notices that the radio unit RU is ready to send the message, the message is transferred to a message transfer running 
circuit 12, which adds to the message infonmation relating to the mobile communications system in question, such as 
validity infonnation (which indicates to which direction the message is going, i.e., from a mobile station to a message 

30 service centre or vice versa), processes the address information into a form required by the mobile communications 
system, and adds to the message the address of the message service centre, as well as the short message identifier 
(SAPI), and forms from the information to be transmitted, e.g., a digital signal for a transmitter 2, and sends the message 
to the radio transmitter branch 2 of the radio unit RU. In the case where the application identifier is placed in bits in the 
address field ADD, the running circuit 1 2 adds to the message the identifier in question. The transmitter branch 2 codes 

35 the signal according to the specifications of the mobile communications system, and fonns, on the basis of the signal 
it receives from the running circuit 12, the frames to be transmitted, which the transmitter sends using radio commu- 
nication to the short message service centre SM-SC, wherefrom they are sent further to the receiver (see Figure 1). 
In the transmitter branch 2, the message is processed according to the mobile communications system, e.g., coding, 
interieaving, ciphering, burst forming, modulating, and transmission. 

40 [0072] In the following, we will discus the implementation and operation of the terminal in receiving application related 
information. When the terminal receives a short message containing information for an application, the message first 
arrives at the radio unit RU. There, at a receiving branch 3, the processing of the message takes place according to 
the mobile communications system, such as reception, demodulating, de-ciphering, de-interleaving, and decoding. If 
the received frame identifier (SAPI) indicates that the message is a short message, it will be transferred into an Inbox 

45 9 of the data processing unit, which can be a memory for storing the message. If the received message is an ordinary 
short message, the DU processor 8 will report the short message received. If the message has an identifier, which 
indicates that it is an application related message, the DU processor 8 will launch the application 17, 18 in question, 
and place the infonnation, from the received message, in the application in accordance with the markings on the 
received message. Hence, the reception of the user message (e.g. short message) will be displayed to a user as 

50 received application related information. 

[0073] A terminal according to the present invention provides a simple way of transmitting and receiving application 
related information. Also the present invention provides a terminal that can have access to a enormous amount of 
service, e.g. by using the described Menu application. By especially using short messages as communication form the 
reaching of the destination is guaranteed, and with the user messages in general an optimum current consumption is 

55 achieved. The use of an authorisation token in relation to a user message describes a new method of adding security 
to a user message. 

[0074] This paper presents the implementation and embodiments of the invention with the help of examples. It is 
obvious to a person skilled in the art, that the invention is not restricted to details of the embodiments presented above, 
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and that the invention can be implemented in another embodiment without deviating from the characteristics of the 
invention. Thus, the presented embodiments should be considered illustrative, but not restricting. Hence, the possibil- 
ities of Implementing and using the invention are only restricted by the enclosed patent claims. Consequently, the 
various options of implementing the invention as determined by the claims, including the equivalent implementations, 
5 also belong to the scope of the present invention. 
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Appendix 1 

<head><titIe>WWW SMS TRE NEXT BUS</title></head> 
<html><body> 
<fornn METHOD=°SMS" 
ACTION="None" 
ENCTYPE="b6" 
> 

<SMS_FORM_INFO 
B-» FORM_TYPE="Req" 
C-» PROVIDER="ErSa" 

SERVICE="TreBu8" 
E-* FORM_NAME=TBReq" 
F-» RESPONSE_FORM="TBRes" 

TARGET_NUMBER="+358505337397" 
H-» SERVICE_CENTER="+358508771010" 
l-» FIELD_NAMES="N" 
J-» PROTOCOL-ID="None" 

> 

<h2><p align=c©nter>Tampere bus traffic SMS query</p></h2> 

<h1 ><p align=center>Tampere</h1></p> 

<table bgcolor=white width=95% ceilspacing=2 border=2> 

<tr><td align=center>Select the bus line, tlie time of departure from the 

temninal for the next bus you want to l<now about, and then press 

'SEND'</td></tr> 

<tr><td align=center>Give the time, if you want to know the times of 
departure of the lines departing after a specific time, otherwise, select 
'Now' 

K-» <SELECT NAME="clo">08:00 
<OPTION>Now 
<OPTION>05:00 
<OPTION>06:00 
<OPTION>07:00 
<OPTION>08:00 
<OPTION>09:00 
<OPTION>10:00 
<OPTiON> 11:00 
<OPTION> 12:00 
<OPTION>13:00 
<OPTION>14:00 
<OPTION>15:00 
<OPTION>16:00 
<OPTION>17:00 
<OPTION>18:00 
<OPTION> 19:00 
<OPTION>20:00 
<OPTION>21:00 
<OPTION>22:00 

Appendix 1 

<OPTION>23:00 
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<OPTION>24:00 
<OPTION>01:00 

</SELECT><P> 
</td></tr> 

L-* <tr><td><input type=raclio checked name="opt1 " 

value="1B1"><b>Line 1 Holvasti - Keskustori</b><:/td></tr> 
<tr><td><input type=radio name="opt1" value="1B2"><b>Line 1 
Harmaia - Keskustori<b></td></tr> 

<tr><td><input type=radio name=:"opt1" value="1B3"><b>Line 1 
Keskustori - Holvasti<b></td></tr> 

<tr><td><input type=radio name="optr value="1B4"><b>Line 1 
Keskustori - Harmala<b></td></tr> 

<tr><td><inpLit type=radio name="opt1" value="2B1"><b>Line 2 
Keskustori - Rahola<b></td></tr> 

<tr><td><input type=radio name="optr value="2B2"><b>Line 2 
Keskustori - Rauhaniemi<b></td></tr> 

<tr><td><input type=radio name="optr value="2B3"><b>Line 2 Rahola - 
Keskustori <b></td></tr> 

<tr><td><input type=radio name="opt1 " value="2B4"><b>Line 2 

Raulianieml - Keskustori<b></td></tr> 

<tr><td align=center><h2><input type=submit 

value="SEND"></td></tr></h2> 

</table> 

</form> 

</body> 

</html> 



Claims 

1 . A method of transferring electronic business cards between a first device and a second device, the second device 
being remote from the first device, and both the first and second device being one of a mobile station capable of 
communicating over a mobile communications network and of a computer having a connection to the mobile com- 
munications network, the method comprising: 

retrieving an electronic business card from a business card application of the first device, said business card 
application containing a plurality of electronic business cards each having a number of data fields; 
transmitting said business card to the second device via the mobile communications network; and 
storing the received business card in a business card application of the second device. 

2. A method according to claim 1 , wherein the data fields are separated by field separators which can be recognised 
by the second device. 

3. A method according to claim 1 , wherein the electronic business card has at least a name as one of the data fields 
and a phone number as another one of the data fields. 

4. A method according to claim 1 , wherein the step of transmitting includes transmitting said business card in a user 



19 



EP 1 276 338 A2 



message. 

5. A method according to claim 4, wherein the user message includes an identifier identifying the message as an 
electronic business card, and wherein the the received business card is addressed to the business card application 
of the second device on basis of said identifier. 

6. A terminal (1 ) having means (2 - 5) for wireless communication, characterised In that the terminal comprises 

a memory (14) for storing electronic business cards each having a number of data fields, 
means (2, 4 - 5, 8. 10 - 12) for sending an electronic business card via a mobile communications networi<, 
means (3 - 5, 8 - 9) for receiving an electronic business card via the mobile communications network and for 
storing a received electronic business card in the memory (14). 

7. A temiinal according to claim 6, characterised in that the terminal further comprises means (2, 4 - 5, 8, 10 - 12) 
for sending said electronic business card in a user message. 

8. A terminal according to claim 7, characterised in that said user message is one of a short message, a message 
according to the standardised SMS message, a message according to the standardised R data field message, a 
message according to the standardised USSD message, a message according to the standardised SOC message, 
and a message according to a wireless packet radio service. 

9. A terminal according to claim 6, characterised in that said user message comprises ASCII characters. 

10. A terminal according to claim 6, characterised in that said user message comprises an identifier identifying said 
user message as an electronic business card. 

11. A terminal according to any one of claims 6-10, characterised in that the terminal is one of a mobile station 
capable of communicating over the mobile communications network and of a computer having a connection to the 
mobile communications network. 
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Tampere bus traffic SMS query 
Tampere 

Select the bus line, the time of departure from the terminal 

for the next bus you want to know about, and then press 'SEND' 



Give the time, if you want to know the times of departure of the lines departing 
after a specified time, otherwise select TMow" 



^ Line 1 Holvasti - Keskustori 

O Line 1 HSrmSla - Keskustori 

Q Line 1 Keskustori - Holvasti 

O Line 1 Keskustori - H^rmalS 

O Line 2 Keskustori - Rahola 

Q Line 2 Keskustori - Rauhaniemi 

O Line 2 Rahola - Keskustori 

Q Line 2 Rauhaniemi - Keskustori 

' ~ I SEND I 



Fig. 7 
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Fig. 8 
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